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A METHOD OF RECORDING AUDIOVISUAL CONTENT IN A 
COMMUNICATIONS NETWORK 

The present invention relates to a method of 
recording audiovisual content in a communications 
5 network. 

One particularly advantageous application of the 
invention is the field of remote recording audiovisual 
content . 

There are prior art methods for the remote recording 

10 of audiovisual content broadcast on broadcast channels of 
a communications network that consist in requesting a 
broadcast channel to broadcast a content selected by the 
user to a personal digital recorder (PDR) situated in the 
user's home, for example. 

15 By way of example, users can find it necessary to 

use this kind of remote recording method if they are far 
from home and realize that they have forgotten to program 
a recording on a PDR while they were at home. 

Using an office computer, mobile telephone, or 

20 personal digital assistant (PDA) , a user can then program 
recording remotely by sending a request to the broadcast 
channel concerned . 

However, although they meet this type of need well, 
■ the above prior art remote recording methods do not solve 

25 other problems associated with recording audiovisual 
content, in particular if the broadcast channel whose 
content the user would like to record cannot be received, 
for example because that channel is not part of the 
package to which the user subscribes or because the 

30 user's receiver can receive only one channel at a time 

and is being used by another person on another broadcast 
channel at the time the content that the user wishes to 
record is broadcast . 

Thus the technical problem to be solved by the 

3 5 present invention is that of proposing a method of 

recording audiovisual content in a communications network 
that would enable users to record audiovisual content 
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that they are unable to record directly on their own 
receivers, either because the content cannot be received 
thereby, or because a receiver is not designed to receive 
more than one broadcast channel at a time. 
5 In accordance with the present invention, the 

solution to the stated technical problem consists in a 
method of recording audiovisual content in a 
communications network including at least one network 
recorder able to record audiovisual content broadcast on 

10 a plurality of broadcast channels, characterized in that 
said audiovisual content is recorded by a network 
recorder at the request of a user having a communications 
terminal able to exchange information with at least one 
network recorder via said communications network, said 

15 method comprising the following steps: 

■ the network recorder declaring itself in the 
network, the declaration indicating at least: 

* a means of access to said recorder, 

* a list of broadcast channels whose broadcast 
2 0 audiovisual content can be recorded by the network 

recorder, 

the user using a terminal to select a network 
recorder able to record at least one required audiovisual 
content and to connect thereto using said access means in 

25 order to request the recording of said at least one 
audiovisual content, said request including an 
identification of said at least one audiovisual content 
to be recorded that consists in a unique reference of 
said content and/or an identification of an instance of 

30 said content consisting of at least the identification of 
the broadcast channel of said instance accompanied by the 
indication of a broadcast time band, and 

the network recorder sending a response to the 
user's recording request containing, if the request is 

35 accepted, an identification of the accepted recording 
request for each content to be recorded. 
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Accordingly, from a PDR, a personal computer, a 
mobile telephone, or a personal assistant, a user can at 
any time request the network recorder to record an 
audiovisual content on any broadcast channel, even those 
5 channels to which the user does not have direct access, 
in order afterwards to transfer the recorded audiovisual 
content to the receiver of the user's choice (PDR, PC, 
PDA) and to watch it at a time when the receiver is 
available . 

10 According to the invention, said time band 

indication includes the broadcast start time and either 
the broadcast end time or the duration of the broadcast 
on the broadcast channel of said instance . 

The invention provides two main ways to access a 

15 network recorder. One way to access a network recorder 
is to use an address of said recorder in the network. 
The other way to access a network recorder is to use a 
directory listing operations specific to the network 
recorders, each network recorder being identified by said 

20 operation. 

More precisely, according to the invention, said 
list of broadcast channels whose broadcast audiovisual 
content the network recorder can record includes the 
address of each broadcast channel, optionally accompanied 

2 5 by the charging policy of the network recorder for each 

broadcast channel. The broadcast channel address is a 
channel identifier codified by a consortium combining 
interested companies and organizations, such as the TV 
Anytime forum. 

3 0 To enable the user to receive the audiovisual 

content recorded by the network recorder subject to 
technical conditions compatible with the user's receiver, 
the invention provides for the declaration of the network 
recorder in the network to contain the conversion 
35 capabilities of said recorder, which relate more 

particularly to bit rate reduction and/or transcoding of 
the audiovisual content . 
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It should also be pointed out that the bit rate and 
transcoding constraints in respect of the audiovisual 
content emanate from the user himself, as the invention 
teaches that said request should contain the conversion 
5 capabilities required by the user for transferring the 
recording to the user's terminal. 

Likewise, the invention provides for the declaration 
of the network recorder in the network to contain the 
protocols that the network recorder can use to transfer 
10 the recorded audio visual content to the user's terminal. 
In other words, this enables the user to select either a 
streaming direct transfer mode or a downloading mode 
(off-line relative to recording in the network) . 

When it receives a recording request, the network 
15 recorder supplies a response to the user who sent the 
request . 

If the request fails and plurality of contents has 
been requested, the response of the network recorder to 
the user's recording request contains a rejected content 

20 identification. Likewise, the response of the recorder 
includes the reason for failure, for example the fact 
that the network recorder does not have access to the 
content requested by the user. 

If the request is accepted, the invention envisages 

25 a number of options in addition to identification of the 
accepted request, namely: the response from the network 
recorder contains said unique reference of the requested 
audiovisual content, the response from the network 
recorder contains the programmed end of recording time 

3 0 and/or the cost of said recording, or the response from 
the network recorder contains the time for which the 
network recorder will keep the recording. 

The recording method of the invention also offers 
the user the option to review and revise a request, by 

35 said method further including the steps of the user 

formulating a request to cancel a recording request that 
has been accepted or to delete a content that has been 
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recorded by the network recorder, that request specifying 
at least the identification of the recording request that 
has been accepted. 

To enable the user to determine at any time the 
5 stage reached by the network recorder in processing a 
request, the recording method of the invention also 
include the steps of : 

• for the user, if the request is accepted, sending 
the network recorder a recording request status request 

10 indicating at least said identification of the accepted 
recording request, and 

• for the network recorder, sending a response to 
the recording request status request containing at least 
the identification of the accepted recording request and 

15 the status of the request. 

Said recording request status request preferably 
contains said unique reference of the content and/or the 
identification of the user. 

The response of the recorder to the recording 
2 0 request status request may take various forms, depending 
on the situation: 

• in the case of a request that has not yet been 
executed, the response to the recording request status 
request contains the unique reference of the content 

2 5 and/or the programmed end date and time, 

• in the event of an unknown request, the response 
to the recording request status request contains the 
unique reference of the content, 

• in the event of failure of the request, the 

3 0 response to the recording request status request contains 

the unique reference of the content, 

• if the content is available, the response to the 
recording request status request contains an address at 
which the recorded content is available. In which case, 

35 the response contains the unique reference of the content 
and/or the time for which the network recorder will keep 
the recording. 
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The following description with reference to the 
appended drawings, which are provided by way of 
non-limiting example, explains in what the invention 
consists and how it may be reduced to practice. 
5 Figure 1 is a general flowchart of the recording 

method of the invention. 

Figure 2 is a flowchart of the recording method of 
the invention in the case of a successful recording 
request . 

10 Figure 3 is a flowchart of the recording method of 

the invention in the case of a failed recording request. 

Figure 4 is a flowchart of the recording method of 
the invention in the case of a successful recording 
request with additional time-delay. 

15 Figure 5 is a flowchart of the recording method of 

the invention in the case of a successful recording 
request followed by a cancellation request. 

Figure 6 is a flowchart of the recording method of 
the invention in the case of a successful recording 

2 0 request followed by a failure to record. 

Figure 7 is a flowchart of the recording method of 
the invention in the case of an unknown recording 
request . 

Figure 1 is a general flowchart of a method of 
25 recording audiovisual (AV) content in a communications 
network . 

That method involves at least one network recorder, 
corresponding to the right-hand portion of Figure 1, able 
to record audiovisual content broadcast on broadcast 
30 channels. Network recorder operators offer a user the 

service of recording on their behalf audiovisual content 
that they are unable to record themselves, for example 
because this is not possible as the user does not have an 
appropriate subscription or does not have access to the 

3 5 broadcast channel that is broadcasting the required AV 

content or because their receiver is already being used 
by another person on another broadcast channel . Network 
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recorders can be provided by operators specializing in 
this type of service or by the broadcast channels 
(television channels) themselves. 

The network recorder records an audiovisual content 
5 at the request of a user, corresponding to the left-hand 
portion of Figure 1, provided with a terminal able to 
exchange information concerning recording requests with 
network recorders via a communications network. 

Initially, the network recorders must declare 

10 themselves on the communications network, either directly 
through a recorder website or indirectly via a directory, 
for example a UDDI (Universal Description Discovery and 
Integration) directory associated with the SOAP (Simple 
Object Access Protocol) exchange technology. In which 

15 case, the directory has to create a particular "Network 
Recorders" heading and list in the directory under that 
heading the network recorders that have been declared. 

The declaration of the existence each network 
recorder in the network (<TV_Record_Se2rvice_Declaration> 

20 data structure) indicates: 

• preferably, an address of the network recorder 
(<RecordServiceAddress> element) , which is the address to 
which the recording request must be sent, and is either 
the address of a website or the address of a directory 

2 5 heading, 

• preferably, a list of the broadcast channels that 
it can record (<DeliverySerxriceList> element) , able to 
contain for each channel : 

* preferably, the address of the broadcast 

30 channel ( " serviceURL" attribute), for example as defined 
by the TV Anytime forum, 

* optionally, the charging policy of the 
recorder for that broadcast channel (<ChargingPolicy> 
element) , 

35 • optionally, the conversion capabilities of the 

recorder (<ConversionCapabilities> element) consisting 
of: 
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* the bit rate reduction capability 

{<Bi trateConversionCapabili ty> element), for example bit 
rate reduction from 4 Mbps to 2 Mbps, 

* the ability to transcode the audiovisual 

5 content (<TranscodingCapability> element) into different 
audiovisual coding formats, such as MPEG2 to MPEG4 
transcoding, 

* optionally, the protocols supported for 
transferring the recorded AV content to the user's 

10 receiver: FTP, streaming, or downloading. 

The user must be in a position to discover the 
existence of network recorders in order to be able to 
select the one able to record the required AV content 
under the best technical, economic and ergonomic 

15 conditions. This can be done: 

• either by defining a particular MIME (Multipurpose 
Internet Mail Extensions) type (e.g. " application/x-TV- 
Record- Service-Declaration") , which, when a file of this 
type is received from a website, activates software on 

20 the user's receiver for interpreting the 

<TV_Record_Service_Declaration> data structure defined 
above , 

• or by using a UDDI directory and defining a new 
"tModel" for AV content recording services enabling any 

25 recorder to declare its existence and its capabilities to 

the directory in the <TV_Record_Service_Declaration> data 

structure defined above. 

Having selected the best-suited network recorder for 

recording the required AV content from a website or a 
3 0 directory, the user sends that recorder a recording 

request (<TV_Record_Service_Request> data structure) 

comprising : 

• preferably, the identification of the user 
(<£7serXd> attribute) if the user has not been identified 

35 some other way, for example at the time of connecting to 
the recorder (log in and password type connection) , 
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• preferably, an identification of the AV content to 
be recorded, which may be: 

* either a unique reference of said content 
("CRID" attribute), essentially a simple identification 

5 of the content as such, 

* or the user's own identification of an 
instance of that content consisting of: 

■ preferably, the identification of the 
broadcast channel ( " serviceURL" attribute), 
10 ■ preferably, the start time ("start" 

attribute) , 

• preferably, the end time ("end" 
attribute) or the duration ("duration" attribute), 

• optionally, the identification of a 
15 particular instance ( " instanceMetada ta Id" attribute), 

• optionally, the conversion capabilities required 
by the user. 

The network recorder's response to the user's 
recording request (<TV_Record_Service_Request_Response> 
20 data structure) contains for each content to be recorded 
an indication: 

• either of the success of the recording request 
(<RecordRequestSuccess> element) , this indication 
containing : 

25 * preferably, the identification of the 

accepted recording request ( "request Id" attribute), 

* optionally, the identification of the 
requested content ( "CRID" attribute) , 

* optionally, the programmed end of recording 
30 time ( "recordEndTime" attribute), 

* optionally, the time to keep the recorded 
content ( "keepDuration" attribute) , 

* optionally, the cost of the recording 
( "recordCost" and "currency" attributes), 

3 5 • or of the failure of the recording request 

(<RecordRequestFailure> element) , this indication 
containing : 
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* preferably, the identification of the 
requested content ( "CRID" attribute), 

* optionally, the reason for failure of the 
request ("KOreason" attribute). 

5 If a recording request is accepted, its status can 

be requested (<TV_Record_Request_Status_Request> data 
structure), the request indicating: 

• preferably, the identification of the accepted 
recording request ( "requestld" attribute), 

10 • optionally, the identification of the content to 

be recorded ("CRID" attribute), 

• optionally, the identification of the user 
(<UserId> attribute) . 

On receiving a request status request, the network 
15 recorder sends a response 

( < TV__Record_Regues t_Sta tus_Response> data structure ) 
containing : 

• in the case of a request that has not yet been 
executed: 

20 * preferably, the identification of the 

accepted recording request ( "request Id" attribute), 

* preferably, the status of the request 
("status" attribute, " runnningRequest" value), 

* optionally, the identification of the 
25 content to be recorded ( "CRID" attribute), 

* optionally, the programmed end date and 
time ( "cal 1 After" attribute), 

• in the case of an unknown request (« request ID » 
attribute not recognized) : 

30 * preferably, the identification of 

the accepted recording request ( "requestld" attribute), 

* preferably, the status of the request 
("status" attribute, "unknownReques t " value), 

* optionally, the identification of the content 
35 to be recorded ("CRID" attribute), 

• in the case of a request that fails (for example 
in the event of an equipment failure) : 



11 



* preferably, the identification of the 
accepted recording request ( "recjuestld" attribute) , 

* preferably, the status of the request 
("status" attribute, "failedRequest" value), 

5 * optionally, the identification of the content 

to be recorded ( "CRID" attribute), 

• in the case of a request that has been completed 
with the recorded content available: 

* preferably, the identification of the 
10 accepted recording request ( "request Id" attribute), 

* preferably, the status of the request 
("status" attribute, "contentAvailable" value), 

* preferably, the means of recovering the 
recorded content ( "con tent URL 11 attribute), 

15 * optionally, the identification of the content 

to be recorded ("CRID" attribute), 

* optionally, the time for which the recorder 
will keep the recorded content ( "keepDuration" 
attribute) . 

20 The user can also request cancellation of a 

recording request (<TV_Record_Request_Cancel> data 
structure) , for example if the user changes his or her 
mind, the cancellation request indicating: 

• preferably, the identification of the accepted 
25 recording request ( "request Id" attribute), 

• optionally, the identification of the content to 
be recorded {"CRID" attribute), 

• optionally, the identification of the user 
(<UserId> attribute) . 

3 0 The user can also request the deletion of an AV 

content that has already been recorded in the network 
(<£ecorded_Content_Delete> data structure) , the deletion 
request indicating : 

• preferably, the identification of the accepted 
35 recording request ( "request Id" attribute), 

• optionally, the identification of the content to 
be recorded ( "CRID" attribute), 
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- optionally, the identification of the user 
(<UserId> attribute) . 

The steps of the recording method that have just 
been generally described with reference to Figure 1 will 
5 now be described in more detail with reference to Figures 
2 to 7 . 

1. Recording audiovisual content in the network from a 
network recorder website. 

1.1. Discovering a network recorder website. 
10 An audiovisual content recorder can make itself 

known by means of an HTML page on a website. 

On clicking on a link indicated on the web page, the 
user's terminal receives a file of a particular MIME 
type : "application/x-TV-Record-Service-Declaration" . 
15 This file contains the following information: 

• preferably, the address of the recorder on the 
network (<RecordServiceAddress> element) , 

• preferably, a list of the channels that it can 
record (<Deli\reryServiceList> element) containing for 

2 0 each channel: 

* preferably, the address of the channel as 
defined by the TV Anytime forum ( " serviceURL" attribute), 

* optionally, the charging policy of the 
recorder for that channel {<ChargingPolicy> element) , 

25 - optionally, the conversion capabilities of the 

recorder (<ConversionCapcibilities> element) , consisting 
Of: 

* a bit rate reduction capability 
( <Bi trateConversionCapabili ty> element) , 

3 0 * an audiovisual content transcoding capability 

(<TranscodingCapability> element) relating to transcoding 
a content into different audiovisual coding formats, 

• optionally, the protocols supported for 
transferring the recorded content to the user's terminal 

3 5 (e.g. only the FTP mode or another mode is always 
proposed by default) . 
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There follows an example of a file declaring a 
recorder in the network: 



<TV_Record_Service_Declaration xmlns:xsi= n http://wvvw.w3.o^g/2001/X^/ILSchema-instance ,, 
5 xsi:noNamespaceSchemaLocation="TVRecServ.xsd n version= n r> 

<RecordServiceAddress>http://www.voi!a.fr/RecordRequestTr</RecordServiceAd 
<ConversionCapabilities> 

<BitrateConversionCapability>true</BitrateConversionCapability> 
<TranscodingCapability>MPEG-K/T ranscodingCapability> 
10 <TranscodingCapability>MPEG-4</TranscodingCapability> 
</ConversionCapabilities> 
<SupportedTransferProtocols> 

<SupportedTransferProtocoi value= M FTP7> 
<SupportedTransferProtocol value="HTTP7> 
1 5 </SupportedTransferProtoco!s> 
<DeliveryServicel_ist> 

<DeliveryService serviceURL="dvb://1 .2.a"> 

<ChargingPolicy xml:lang="en">3 USD for AV contents produced in the last 3 months, 1 USD for 
the other contents </Charging Pol icy > 
2 0 </DeliveryService> 

<DeliveryService serviceURL="dvb://1 .2.b7> 
<DeliveryService serviceURL="dvb://1 .2.c7> 
</DeliveryServiceList> 
</TV_Record_Service_Decla ration > 

25 

This table is used to declare a broadcast 
audiovisual content recorder to which requests may be 
submitted at the address indicated by the 
<RecordServ r iceAddress> element for content delivery 

30 services or broadcast channels (television channels) 
indicated by the <Deli veryServiceURL> elements. 

Accordingly, if the user wishes to record a content 
broadcast by one of the broadcast channels declared in 
this way, if the user's terminal does not receive the 

35 channel broadcasting the selected content directly or is 
unable to receive it at the time the content is 
broadcast, it can request the recording of that content 
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at the address indicated in the <RecordServiceAddress> 
element . 

1.2. Requesting by the user of recording in the 
network . 

5 When a user has discovered in the preceding step 

that a network recorder is able to record audiovisual 
content broadcast by a particular broadcast channel and 
the user wishes to activate a network recorder, the user 
must send it the request <TV_Record_Service_Request> , at 
10 the address indicated by the <RecordServiceAddress> 
element of the above table, with the following 
information : 

• preferably, the identification of the user 
("Userld" attribute), 

15 • optionally, the identification of the protocol to 

be used to transfer the content after recording, 

• optionally, the identification of the coding 
required for the content to be recorded (which may call 
for transcoding in the recorder) , 

20 • preferably, the identification of the content to 

be recorded ("CRID" attribute), 

• optionally, the identification of an instance of 
that content consisting of: 

* preferably, the identification of the 
25 television channel ( " serviceURL" attribute), 

* preferably, the start time ("start" 
attribute) , 

* preferably, the end time ( "end" attribute) or 
the duration ("duration" attribute), 

30 * optionally, the identity of a particular 

instance {" instanceMetadatald" attribute) . 

There follows an example of a file requesting 
recording in the network of two contents using FTP as the 
recorded content recovery protocol and transcoding to 

35 MPEG-4 with a maximum bit rate of 1500 kbps for the 
"crid : //hbc . com/f oxes/episodel 1 " content on the 
television channel "dvb:// 1 . 4ee2 . 3f 5/ " and the 
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"crid : //chl . com/serie/epl2 11 content on the channel 
"dvb: //l .4ee2 . 3f4 ;4f 5/" : 

<TV_Record_Service_Request xmlns:xsi= ^ http://www.w3.org/2001/XMLSchema-instance ,, 
5 xsi:noNamespaceSchemaLocation= n TVRecServ.xsd n userld=*'X3YZDFdeGH49 , '> 
<RequestedTransferProtocol>FTP</RequestedTransferProtocxDl> 
<Transcoding>MPEG-4</Transcoding> 
<MaxBitRate>1 500</MaxBitRate> 

<Contentldentification crid= n crid://hbc.com/foxes/episode11" serviceURL="dvb:// 1.4ee2.3f5r start="2001- 
1 0 04-07T1 9:00:00.00+01 :00 w duration="PT1 H30M7> 

<Contentldentification crid="crid://ch1.com/serie/ep12" serviceURL="dvb://1.4ee2.3f4;4f5r start="2003-06- 
27T1 2:30:00.00+01:00" duration="PT0H30M M instanceMetadatald="imi: broadcast/1 7> 
</TV_Record_Service_Request> 

15 Each content to be recorded is identified by its 

CRID, the serviceURL that will deliver the content, its 
start time and its duration (or its end time) , and where 
applicable its instance identification. 

The response < TV_Record_Service_Reques t_Response> 
2 0 received in return indicates for each content whose 
recording has been requested: 

• either the success of the recording request 
(<RGCordRequestSuccess> element) (Figure 2), giving: 

* preferably, the identification of the 
25 accepted recording request ( "requestld" attribute), 

* preferably, the identification of the 
requested content {"CRID" attribute), if a plurality of 
contents was requested in the same request, 

* optionally, the identification of the 

30 requested content ( "CRJD"attribute) , if a single content 
was requested, 

* optionally, the programmed end of recording 
time ( "recordEndTime" attribute) , 

* optionally, the time to keep the recorded 
35 content ( "keepDura tion " attribute), 

* optionally, the recording cost (" recordCost" 
and "currency" attributes) , 



16 



• or the failure of the recording request 
(< J Recordi?eqruestFailure> element) (Figure 3), giving: 

* preferably, the identification of the content 
for which the request has failed ("CRID" attribute), if a 

5 plurality of contents was requested in the same request, 

* optionally, the identification of the 
requested content ("CRID" attribute), if a single content 
was requested, 

* optionally, the reason for failure of the 
10 request ( "KOreason " attribute). 

There follows an example of a response to a 
recording request with success for two contents (the time 
to keep and the cost to be paid the being indicated for 
the second one) and failure for two others: 

15 

<TV_Record_Service_Request_Response xmlns:xsi= w http://www. w3.org/200 1/XMLSchema-instance n 
xsi:noNamespaceSchemaLocation=HVRecServ.xsd w > 

<RecordRequestSuccess crid= n crid://hbc.com/foxes/episode1 1" requestld="12456XD34" 
recordEndTime= M 2003-04-07T20:30:00.00+01:007> 

2 0 <RecordRequestSuccess crid="crid://zzz.com/movie/title1" requestld="156WQ77" record EndTime="2003-04- 

07T20:30:00.00+01:00" keepDu ration = M PT24H" recordCost^" currency="USD7> 
<RecordRequestFailure crid="crid://ch1 .com/serie/ep1 2" KOreason="unknownCRID7> 
<RecordRequestFailure crid= M crid://chaine5.com/film1 5" KOreason="unavailableServiceURL7> 
</TV_Record_Service_Request_Response> 

25 

1.3. Management of a request for recording in the 
network. 

After accepting a request for recording in the 
network, the network recorder is able to monitor changes 

3 0 in the scheduling of the broadcasting of AV contents and 

to reprogram the recording of the requested contents 
accordingly . 

After a request for recording in the network is 
accepted, the user has a number of options: 
35 • to cancel the recording request (if the cost is 

too high or the user changes his or her mind) , 
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• to track the status of a recording request (to 
find out if the content has been reprogrammed at another 
date or time, or if the recording is finished) . 

To cancel a recording request, the user must send a 
5 recording request cancellation request 

(<TV_Record_RequGst_Cancel> date structure) (Figure 5) 
containing : 

• preferably, the identification of the accepted 
recording request ( "request Id" attribute), 

10 • optionally, the identification of the content to 

be recorded ( "CRID" attribute), 

• optionally, the identification of the user 
(<UserId> attribute) . 

There follows an example of a recording request 
15 cancellation request: 

<TV_Record_Request_Cancel xmlns:xsi= w http://www. w3.org/200 1/XMLSchema- instance" 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd' 1 crid="crid://hbc.com/foxes/episode1 1 M 
requestld="1 2456XD347> 

20 

No response is expected from the recorder. 
To track the status of a recording request, the user 
must send a recording request status request 
( < TV^ecord^eqrues t_Sta tus_Reques t> data structure ) 
25 (Figure 2) containing: 

• preferably, the identification of the accepted 
recording request ( "reguestld" attribute) , 

■ optionally, the identification of the content to 
be recorded ( "CRID" attribute) , 
30 • optionally, the identification of the user 

(<UserId> attribute) . 

There follows an example of a "recording status 
request" request: 

3 5 <TV_Record_Request_Status_Request xmins:xsi="http://www. w3.org/200 1/XMLSchema-instance w 
xsi:noNamespaceSchemaLocation=HVRecServ.xsd M crid="crid://hbc.com/foxes/episode1 1" 
requestld= w 1 2456XD347> 
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Several responses are possible. If the content has 
not yet been recorded (Figure 4) , the response from the 
recorder includes : 
5 • preferably, the identification of the accepted 

recording request ( "reqruestJd" attribute), 

• preferably, the status of the request ("status" 
attribute, " runnningReguest" value) , 

• optionally, the identification of the content to 
10 be recorded ( "CRID" attribute), 

• optionally, the programmed end date and time 
("callAfter" attribute). 

There follows an example of a "content not yet 
recorded" response : 

15 

<TV_Record_Request_Status_Response xmlns:xsi= M http://www.w3.org/2001/XMLSchema-instance w 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd n crid= n crid://hbc.com/foxes/episode1 1" 
requestld="12456XD34" status= n runningRequest" ="2003-06-27T1 4:30:00.00+0 1 :007> 

2 0 The "callAfter" attribute enables the terminal to 

program a timer for repeating a recording status request 
if there is any chance of obtaining a different response. 
This is the case if the broadcast time of a content has 
changed. 

25 If the request is not recognized as valid (Figure 

7), the response from the recorder includes: 

• preferably, the identification of the accepted 
recording request ( "reqrues tXd" attribute), 

• preferably, the status of the request ("status" 
30 attribute, "unknownRequest " value) , 

• optionally, the identification of the content to 
be recorded {"CRID" attribute). 

There follows an example of an "unknown recording 
request " response : 



35 
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<TV_Record_Request_Status_Response xmlns:xsi="http://www. w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd w crid="crid://hbc.com/foxes/episode1 1" 
requestld^l 2456XD34" status ="unknownRequest7> 

5 This situation can arise if the user's terminal 

interrogates the network recorder after the end date for 
keeping a recorded content . 

If the request has failed (Figure 6) , the recorder 
responds with: 

10 • preferably, the identification of the accepted 

recording request ( " requestld" attribute), 

• preferably, the status of the request ("status" 
attribute, " failedRecjuest" value) , 

• optionally, the identification of the content to 
15 be recorded ("CRID" attribute). 

There follows an example of a "failed recording 
request " response : 

<TV_Record_Request_Status_Response xmlns:xsi= w http://www. w3.org/2001/XMLSchema-instance" 

2 0 xsi:noN a mespaceSchema Location -TVRecServ.xsd" crid="crid://hbc. com/foxes/episode 1 1" 

requestld="1 2456XD34" status= w failedRequest7> 

If recording has finished and the content is 
available, the response from the recorder includes: 
25 ■ preferably, the identification of the accepted 

recording request ("requestld 11 attribute), 

• preferably, the status of the request {"status" 
attribute, " con ten tAvail able" value) , 

• optionally, the identification of the content to 
30 be recorded ( "CRID" attribute), 

• optionally, the time to keep the recorded content 
in the recorder ( "keepDura tion " attribute), 

• preferably, the means of recovering the recorded 
content ( " con ten t URL " attribute) . 

3 5 There follows an example of a "recorded content 

available in the recorder" response: 
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<TV_Record_Request_Status_Response xmlns:xsi="http:/ArtWw.w3.o^g/2001/XMLSchema-instance ,, 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd*' crid= w crid://hbc.com/foxes/episode11" 
requestld= tt 1 2456XD34" status= w contentAvailable w 
contentURL="ftp://login:password@ftp.tvrs.fr/user1/av12.mpg7> 

5 

1.4 Transferring and deleting a content recorded in 
the network. 

If the recorder responds to a content recording 
request status request by indicating that the content is 
10 available, the user's terminal can then download the 

content, the address of the content being indicated by 
the <contentURL> attribute of the response from the 
recorder . 

The recording will be deleted automatically after a 
15 certain time or in response to a specific request from 
the terminal containing: 

• preferably, the identification of the accepted 
recording request ( "request Jd" attribute), 

• optionally, the identification of the content to 
20 be recorded ("CRID" attribute), 

• optionally, the identification of the user 
(<UserId> attribute) . 

There follows an example of a request to delete a 
recording: 

25 

<Recorded_Content_Delete xmlns:xsi= M http://www.w3.org/2001/XMLSchema-instance n 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd" crid = M crid://hbc. com/foxes/episode 1 1" 
requestld= M 1 2456XD347> 

3 0 No response is expected from the recorder. 

2 . Recording of an audiovisual content by a network 
recorder using UDDI and SOAP. 

2 . 1 Declaring the network recorder using UDDI (web 
service) . 

35 The technology of web services and in particular of 

UDDI (Universal Description, Discovery and Integration) 
services enables recorders of audiovisual content 
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broadcast in the network by broadcast channels to be 
entered into a directory: the UDDI directory. 

The SOAP (Simple Object Access Protocol) technology 
is used to exchange XML-type data structures. 
5 It must be possible to record in the UDDI directory: 

* a new service category (or heading) : the service 
for recording audiovisual content in the network with its 
access point and the operations accepted from users' 
terminals , 

10 • a search criterion: the identifier of each 

broadcast channel (television channel) . 

Thus a user terminal looking for a network recorder 
can consult the directory, supplying one or more 
broadcast channel (television channel) identifiers and 

15 requesting in return a means of addressing directly 
recorders that satisfy the search criteria. 

The new search criterion in the UDDI directory that 
consists of the television channel identifier, for 
example, must be the subject of the definition of a new 

20 UDDI tModel, here called "serviceURL" (in conformance 

with section 1.6.4 of the UDDI specifications relating to 
the definition of "tModel"), to declare the audiovisual 
content broadcast channels. It is given the name " tv- 
record-org: serviceURL" . This is an authority that must 

25 request the recording of this new "tModel". The entity 
" tv-record-org " is any entity, for example " tv- anytime - 
org". This leads to declaring a key with the same name 
"uddi : tv- record. org : serviceURL " . 

The declaration of that key also includes references 

30 to the specifications of this "tModel" by the 
organization requesting its insertion 

"<overviewDocxoverviewURL> " and the "<categoryBag> " 
element contains standard information included in any 
"tModel " declaration. 

35 

<tModel tModelKey="uddi:tv-record.org:serviceURL tt > 
<name>tv-record-org:serviceURL</name> 



22 

description xml:lang= w en ,, >Category system for each delivery service handled by a recording 
service</description> 
<overviewDoc> 
<overviewURL useType=' , text n > 

ftp://pub:pub@ftp.francetelecom.fr/pub/Spe<^Record_tModel.zip 
</overviewURL> 
</overviewDoc> 
<categoryBag> 
<keyed Reference keyName="uddi-org:types:categorization" 
keyValue="categorization" tModelKey="uddi:uddi.org:categorization:types7> 

<keyedReference keyName="uddi-org:types:unchecked" 
keyValue= M unchecked n tModelKey= M uddi: uddi.org: categorization :types7> 

</categoryBag> 
</tModel> 

It is also necessary to define a "tModel port" for 
sending requests to the audiovisual content recorder as 
follows: this "tModel" describes the service for 
transferring " submi t_Da ta " requests to the content 
recorder in the network, the use of which will be 
illustrated later : 

<tModel tModelKey="uddi:tv-record.org:submit_Data_v1 0"> 
<name>tv-record-org:submit_Data_v10</name> 

2 5 description xml:lang="en">TV Record WSDL interface for submit_Data port</description> 

<overviewDoc> 
<overviewURL useType="wsd I Interface'^ 

http://www.tv-record.Org/wsdl/tvr_transport_v10.wsdl#submit_Data_SOAP 
</overviewURL> 

3 0 </overviewDoc> 

<overviewDoc> 
<overviewURL useType= M texT> 

ftp://tvr:tvr@ftp.voila.fr/spec/tvr_xxV10.zip 
</overviewURL> 
3 5 </overviewDoc> 
<categoryBag> 

<keyedReference keyName="uddi-org:types:wsdr keyValue="wsdlSpec" 
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tModelKey= n uddi:uddi.org:categorization:types7> 
<keyed Reference keyName="uddi-org:types:soap" keyValue="soapSpec" 

tModel Key = n u66 iiuddi.org: categorization :types7> 
<keyed Reference keyName="uddi-org:types:xml" keyValue= n xmlSpec n 
5 tMod e!Key="udd i:uddi.org: categorization :types7> 

<keyed Reference keyName="uddi-org:types:specification" 
keyValue="specification" tModel Key = n uddi:uddi. org :categorization:types7> 
</categoryBag> 
</tModel> 

10 

To make itself known, a broadcast audiovisual 
content recorder must declare its recording capabilities 
using the " save_binding" method (see the UDDI API 
publication) , assuming that the appropriate parental 
15 structures "businessEntity" and "businessService" have 

already been declared, referring to the "tModel" defined 
previously : 

<save_binding xmlns= M urn:uddi-org:api_v3"> 
2 0 <bindingTemplate> 

description xml:lang-'fr ,, >Declaration of an audiovisual content recording service for one or more 
television channels </description> 
<accessPoint useType="endPoint"> 
http://www.voila.fr/movies 

2 5 </accessPoint> 

<tModellnstanceDetails> 
<tModel Instance Info tModel Key="uddi:tv-record. org :submit_Data_v10"> 
<instanceDetails> 
<instanceParms><![CDATA[ 

3 0 <?xml version= M 1 .0" encoding="utf-8"?> 

<describe_submit_Data_Result serviceVersion="3" 

xm I ns=" http://www.tv-a nytime.org/200271 1 /trans port"> 
<ConversionCapabilities> 
<BitrateConversionCapability>true</BitrateConversionCapability> 
3 5 <TranscodingCapability>MPEG-1 </TranscodingCapability> 
<TranscodingCapability>MPEG-4</TranscodingCapability> 
</ConversionCapabilities> 
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<SupportedTransferProtoco!s> 
<SupportedTransferProtocol value="FTP7> 
<SupportedTransferProtocol value="HTTP7> 
</SupportedTransferProtocols> 
5 <DeliveryServiceList> 

<DeliveryService serviceURL="dvb://1 .2.a"> 

<ChargjngPolicy xml:lang =,, en w >3 USD for AV contents produced in the last 3 months, 1 USD for the other 
contents </Charging Pol icy> 
</DeliveryService> 
1 0 <DeliveryService serviceURL= M dvb://1 .2.b7> 
<DeliveryService serviceURL= w dvb://1 .2.c7> 
</DeIiveryServiceList> 

</describe_submit_Data_Result> 
]]></instanceParms> 
1 5 </instanceDetai!s> 

</tModel I nstancel nfo> 
</tModellnstanceDetails> 
<categoryBag> 

<keyed Reference tModelKey="uddi:tv-record.org:serviceURL M 
2 0 keyValue= M dvb://1 .2.a7> 

<keyed Reference tMod el Key="uddi: tv-record.org: service URL" 

keyValue= M dvb://1.2.b7> 
< keyed Reference tModelKey="uddi:tv-record.org:serviceURL n 

keyValue="dvb://1 .2.c7> 

2 5 </categoryBag> 

</bindingTemplate> 
</save_binding> 

The <accessPoint> element provides the HTTP address 

3 0 of the recorder to which the " submi t_Da ta " request must 

be sent . 

The <instancePaz777s> element contains the declaration 
of what may be expected of the recorder (content of the 
data structure <TV__Record_Service_Declaration> defined 
35 for the first embodiment) which defines the transcoding, 
bit rate production and transfer protocol capabilities, 
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the list of recordable broadcast channels and the 
charging policy. 

The <categoryBag> element contains a list of the 
broadcast channels that the recorder is able to record. 
5 2.2 Discovering a network recorder using a web 

service . 

The technology of web services and of UDDI 
(Universal Description, Discovery and Integration) 
services in particular also offers terminals the option, 
10 if they have an Internet connection, of discovering 

broadcast audiovisual content recorders by consulting the 
directory, without necessitating any prior knowledge. 

Thus any terminal can use a node of the UDDI 
business directory (which has well known addresses) to 
15 find broadcast individual content recorders using the 
<find_binding> command as shown below: 



<find_binding xmlns="urn:uddi-org:apLv3'*> 
<tModelBag> 

20 <tModelKey>uddi:tv-record.org:submit_Data_v10</tModelKey> 
</tModelBag> 
<categoryBag> 

<keyed Reference tMode!Key="uddi:tv-recx)rd.org:serviceURL" 
keyValue= M dvb://1 .2.a7> 
2 5 < keyed Reference tModelKey-'uddiitv-record.orgiserviceURL" 

keyValue="dvb://1 .2.c7> 
</categoryBag> 
</find_binding> 



3 0 In this example, the terminal is looking for a 

network recorder for the channels or television channels 
"dvb://l.2 .a" and "dvb : /l . 2 . c " . 

In response, the terminal receives a 
<bindingTemplate> list that matches its request (recorded 
3 5 in the directory of services by the command 
<sa.ve_binding>) . 

2.3 Requesting recording in the network 
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After choosing an audiovisual content recorder, the 
terminal can send the following request using the SOAP 
(Simple Object Access Protocol) to request the recording 
of a content (the request encapsulating the 
5 <TV_Record_Service_Request> request defined in the 
preceding embodiment) : 

POST /tvr/md-service HTTP/1 .0 
Host: www.voila.fr 
1 0 Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn 
Accept- Encoding: deflate 
SOAPAction: "submit_Data" 

1 5 <?xmi version- '1 .0" encoding="UTF-8"?> 

<Envelope xmlns-' http://schemas.xmlsoap.org/soap/enveloper> 
<Body> 

<submit_Data xmlns="http://www.tv-record. org/2002/1 1 /trans port"> 
<TV_Record_Service_Request 
2 0 xm I ns:xsi -'http://www.w3.org/2001/XMLScherria-insta nee" 

xsi:noNamespaceSchemaLocation="TVRecServ.xsd" userld="XcGHJ63DX"> 
<RequestedTransferProtocol>FTP</RequestedTransferProtocol> 
<Transcoding>MPEG-4</Transcoding> 
<MaxBitRate>1500</MaxBitRate> 

2 5 <Contentldentification crid= M crid://hbc.com/foxes/episode1 1" 

serviceURL="dvb:// 1.4ee2.3f5T 

start="2001-04-07T19:00:00.00+01 :00" duration="PT1 H30M7> 
<Contentldentification crid="crid://ch1 .com/serie/ep12" 
serviceURL="dvb://1 .4ee2.3f4;4f5/" 

3 0 start="2003-06-27T1 2:30:00.00+01:00" duration= M PT0H30M" 

instanceMetadata Id ="imi: broadcast/ 1 7> 
</TV_Record_Service_Req uest> 
</submit_Data> 
</Body> 
3 5 </Envelope> 
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In return the terminal receives the following 
response for recording requests that have succeeded and 
other recording requests that have failed: 

5 HTTP/1.1 200 OK 

Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn 
Content-Encoding: deflate 

1 0 <?xml version="1 .0" encoding= n UTF-8 n ?> 

<Envelope xmlns="http://www.w3.org/2002/06/soap-enve!ope"> 
<Body> 

<submit_Data_Result xmlns=" http://schemas.xmlsoap.org/soap/enveloper> 
<TV_Record_Service_Request_Response 
1 5 xmlns:xsi="http://w\ww.w3.org/2001/XMLSchema-instance M 
xsi:noNamespaceSchemaLocation="TVRecServ.xsd"> 
<RecordRequestSuccess end ="crid://h bc.com/foxes/episode1 1" 
requestld="12456XD34" 

recordEndTime="2003-04-07T20:30:00.00+01:007> 
2 0 <RecordRequestSuccess crid="crid://z2z.com/movie/title1 " 

requestld= M 156WQ77" 

recordEndTime-'2003-04-07T20:30:00.00+01:00" 
keepDuration="PT24H" record Cost="2 M currency="USD7> 
<RecordRequestFailure crid="crid://ch1 xom/serie/ep12 n 

2 5 KOreason="unknownCRID7> 

<RecordRequestFailure crid="crid://chaine5.com/film15" 
KOreason="unavailableServiceURL7> 
</TV_Record_Service_Request_Response> 
</submit_Data_Result> 

3 0 </Body> 

</Envelope> 



The same procedure is used to encapsulate other 
requests defined in the preceding embodiment for other 
3 5 steps of recording audiovisual content in the network. 



